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Sir: 

I. REAL PARTY IN INTEREST 

The real party in interest is the assignee, Telefonaktiebolaget LM Ericsson 
(publ), a Swedish corporation. 
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II. RELATED APPEALS AND INTERFERENCES 

There are no other appeals related to this subject application. There are no 
interferences related to this subject application. 

IIL STATUS OF CLAIMS 

Claims 52-76 are pending. Claims 52-55, 57, 59, 60, and 68-76 stand 
rejected under 35 U.S.C. §103 as being unpatentable over "Engineering Modelling 
Concepts (DPE Architecture) Version 2.0" to Tina-C Deliverable, (hereafter 
"Tina-C"), in view of U.S. Patent 5,517,677 to Moon. Claims 56 and 65 stand 
rejected under 35 U.S.C. §103 as being unpatentable over Tina-C, Moon, and 
Puder. Claims 61-64 stand rejected under 35 U.S.C. §103 as being unpatentable 
over Tina-C, Moon, and Tokmakoff. Claims 58, 66, and 67 stand rejected under 
35 U.S.C. §103 as being unpatentable over Tina-C, Moon, and Leydekkers. 

IV. STATUS OF AMENDMENTS 

It is uncertain whether the amendment filed after final on September 7, 
2004 is entered for purposes of Appeal. To date, Applicant has not received any 
communication from the Examiner acknowledging or responding to the after final 
amendment. In telephone conversations with the Examiner in early October 2004, 
he indicated that the file was inaccessible because it was being imaged. 
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V. SUMMARY OF THE CLAIMED SUBJECT MATTER 

The claims are directed to an arrangement for simplifying the design and 
implementation of mobile services in a distributed communications system. A 
distributed communications system employs distributed hardware and software. 
In Open Distributed Processing (ODP) adopted by the Telecommunication 
Information Networking Architecture (TINA), a telecommunication application is 
realized by a set of interacting computation objects which rely on an abstract 
infrastructure called a distributed processing environment (DPE). Figure 1 
illustrates a DPE example. A DPE node is a unit of resource administration that 
provides support to the DPE architecture. The DPE "hides" the complex details of 
mechanisms used to overcome problems associated with distribution and is 
commonly referred to as "distribution transparency" in the ODP reference model. 

The distribution transparenices recognized and defined by ODP/TINA are 
listed on page 2 of the specification. But these defined distribution transparencies 
do not support mobility. Mobility allows the communications system to monitor a 
current location of a mobile user equipment and to support a connection with a 
mobile user equipment, even as the mobile user equipment moves across various 
geographic coverage areas. Mobility is offered in existing cellular 
communications systems like GSM, UPT, and others but not in a transparent way. 
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Because ODP/TINA provides an efficient framework for designing and 
implementing distributed applications in communications networks, it was 
assumed that mobility would be inherently supported. That assumption was 
wrong. In order to design a new communications application, the designer must 
therefore be knowledgeable about and specifically design in mobility support 
functions. But this defeats the point of distribution transparency. 

The invention adds mobility transparency to the distribution transparencies 
that exist in the ODP adopted by TINA. Mobility transparency hides the various 
mechanisms and functions needed to support mobility for any new mobile 
communications application being designed. As a result, such mobile 
communications applications may be designed more simply and efficiently. 

The detailed description offers three non-limiting, example alternatives for 
adding mobility transparency to a distributed processing based communications 
system referred to as: the "in-line alternative," the "broker alternative," and the 
"proxy alternative." Each alternative introduces necessary mobility functions M 
which include, for example, terminal support, personal support, session support, 
and mobility-related support. By providing mobility transparency, the design and 
implementation of mobile applications are greatly simplified and are no more 
complicated than the design and implementation of fixed applications. This also 
allows existing fixed applications to be transformed into mobile applications. 
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Claim 52 recites "means for supporting one or more transparencies in the 
DPE including access, location, or failure transparencies." Reference is made to 
the DPE physical infrastructure shown in Figure 1 and to the access, location and 
failure distribution transparencies described on page 2 implemented using 
hardware and software in the DPE infrastructure. Claim 52 recites "means for 
supporting mobile radio terminal mobility transparency in the DPE." Reference is 
made to the DPE physical infrastructure shown in Figure 1, to the description of 
the mobility functions introduced described on pages 7-8, and to Figures 3, 5-7, 
11, and 12 along with the supporting text related to supporting mobility 
transparency in the DPE implemented using hardware and software in the DPE 
infrastructure. 

Claim 55 includes "means for mapping computational objects to 
engineering objects (EO) so as to be non-visible in a computational model of the 
application program." Reference is made to Figures 3, 6, and 12 which illustrate 
mapping examples implemented using hardware and software in the DPE 
infrastructure. 

Claim 57 includes "means for effecting an interaction between 
computational objects belonging to a same cluster is effected directly using one or 
more method calls," and "means for effecting communication between 
computational objects located in a telecom system domain and in different clusters 
through a channel including stubs, binders, and protocols." Reference is made to 
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Figure 3, 6, 8, and 12 and the associated descriptive text which are implemented 
using hardware and software in the DPE infrastructure. 

Claim 60 includes "means for sending a message to a routing broker." 
Reference is made to Figure 4 and supporting text implemented using hardware 
and software in the DPE infrastructure. 

Claim 74 includes "means for registering in the mobility function first and 
second objects in different domains." Reference is made to Figures 7 and 8 along 
with supporting text implemented using hardware and software in the DPE 
infrastructure. Claim 74 also includes "means for defining and registering a proxy 
for the object the proxy represents." Reference is made to Figures 9-12 along with 
supporting text implemented using hardware and software in the DPE 
infrastructure. 

Claim 76 includes "means for introducing a redirection function on the 
DPE and for generating a special stub for a dynamic object." Reference is made to 
Figure 1 1 and supporting text implemented using hardware and software in the 
DPE infrastructure. 

VL GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The primary rejection to be reviewed on appeal is the obviousness rejection 
based on Tina-C and Moon. In addition, the rejections based on Tina-C, Moon, 
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and Puder; Tina-C, Moon, and Leydekkers; Tina-C, Moon, and Tokmakoff should 
also be reviewed. 

VII, ARGUMENT 

A. Tina-C and Moon Do Not Disclose or Suggest Claim 52 

The Examiner states Tina-C "teaches an arrangement for simplifying the 
design and implementation of mobile services in a communications system," 
referring to pages 5-9/5-10. Applicant respectfully disagrees. Tina-C does not 
teach simplifying the design and implementation of mobile communication 
services. The text in lines 5-9 and 5-10 relates to service and user session 
managers and describes processing a new video conference service session request 
(see Figure 5-5). There is no teaching here of mobile services. 

The Examiner then goes on to admit that Tina-C fails to disclose: 

means for supporting mobile radio terminal mobility 
transparency such that an application program being 
executed at a mobile ratio terminal located in one radio 
service area serviced via one radio base station is not 
interpreted or hindered in its execution when the 
mobile radio terminal moves to another radio service 
area serviced via another radio base station. 

For these deficiencies, the Examiner turns to the Moon patent which relates to 
mobile radios scanning various channels in a trunked radio system to determine if 
an incoming call is directed to that radio. See column 1, lines 42-45. 
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The problem to which Moon is directed is the large number of home 
channel scannings that a trunked mobile radio must perform in multi-system areas. 
The mobile radio must scan the home channel of each authorized system and 
compare various identification codes to determine if an incoming call is intended 
for the mobile radio. See column 2, lines 15-23 as well as column 3, lines 24-31. 
Moon uses an adaptive queue embedded in the scanning sequence in which entries 
are continually updated based upon a metric that is shown by past history to be 
more often used by this mobile radio than other sequence entries. See column 3, 
lines 51-57. This adaptive queue is particularly helpful when the mobile radio is 
roaming between different geographical areas, as is explained in column 8, lines 
29-38, referenced by the Examiner. 

Mobility has been supported for roaming mobile terminals in trunked radio 
systems and in conventional cellular radio systems for quite some time. But claim 
52 is not simply directed to supporting mobile radio terminal mobility as it appears 
the Examiner is suggesting. To the contrary, claim 52 recites supporting mobile 
terminal: 

mobility transparency in the DPE such that an 
application program being executed at a mobile 
terminal located in one radio service area serviced via 
one radio base station is not interrupted or hindered in 
its execution when the mobile radio terminal moves to 
another radio service area serviced via another radio 
base station. 
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First, there is no teaching of a distributed processing environment in Moon. 
Second, Moon's adaptive scanning technique, which facilitates mobile terminal 
roaming, does not describe or support mobility transparency in a distributed 
processing environment. As a result, applications designers in Moon's system 
must be aware of the details of how mobility is implemented in order to design 
new communications applications that support mobility. 

Nor is it clear how a trunked radio, adaptive scanning technique for use in a 
roaming mobile terminal would be employed in a distributed process environment 
to support mobility transparency. First, mobility transparency is supported in the 
DPE network and not in a mobile terminal. Moon's scanning is performed in the 
terminal — not in the network. Second, Moon does not detail a particular roaming 
scheme for supporting mobility transparency even in a centralized processing 
environment, which is what Moon's conventional trunked communications system 
is. Third, the particulars of how mobility is accomplished are not disclosed by 
Moon. Fourth, the handover and roaming mechanisms that might be used in a 
mobility scheme in Moon are presumably centralized rather then distributed. 

B. There Is No Legal Motivation to Combine Tina-C and Moon 

The Examiner suggests that Moon's mobile radio scanning could be 
combined with Tina-C because it would improve the Tina-C system "by providing 
enhanced roaming feature of mobile radios and telephone." But Tina-C does not 
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disclose any roaming feature, and therefore, there is nothing to be enhanced. 

There also is no teaching in Moon or Tina-C of supporting any kind of mobility 

transparency in a distributed processing environment. Nor does either describe 

how mobility transparency would be implemented in a distributed data processing 

environment. 

The Federal Circuit prohibits: 

rejecting patents solely by finding prior art corollaries 
for the claimed elements [because this] would permit 
an Examiner to use the claimed invention itself as a 
blueprint for piecing together elements in the prior art 
to defeat the patentability of the claimed invention. 

In re RouffeU 149 F.3d 1350, 1357 (Fed. Cir. 1998). Such an approach would be 
"an illogical and inappropriate process by which to determine patentability. " 
Sensonics, Inc. v. Aerosonic Corp. 81 F.3d 1566, 1570 (Fed. Cir. 1996). Yet, this 
is the very approach that the Examiner is taking in an attempt to combine Moon 
with Tina-C. There is no motivation to combine them absent the motivation of 
trying to reject the instant claims. 

The Rouffet Court stated, "the Examiner must show reasons that the skilled 
artisan, confronted with the same problems as the inventor and no knowledge of 
the claimed invention, would select the elements from the prior art references for 
the combination in the mannered claimed." In re Rouffet, 149 F.3d at 1357. The 
Examiner has not shown where either Tina-C or Moon recognized or confronted 
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the same problem as the inventor — namely, how to provide mobility transparency 
in a distributed processing environment. 

Indeed, in November 1997, the inventor delivered a paper at a TINA-C 
Conference in Chile entitled, "Terminal Mobility Support in TINA-C." 1 That 
article demonstrated that the TINA-C architecture does not support mobile 
terminal mobility. See, for example, the Abstract of this article which states "as 
shown in [1] Access and Location transparencies defined for Open Distributed 
Processing (ODP) and TINA-C are insufficient to support terminal mobility since 
interoperability between DPE platforms is not guaranteed at all times" (emphasis 
added). 

Neither Tina-C nor Moon disclose any solution to this inoperability 
between DPE platforms which would be necessary to support roaming and 
terminal mobility. Thus, the combination of Tina-C and Moon is not proper as a 
matter of law. In view of that fact and the fact that their combined teachings fail 
to disclose the claimed "means for supporting mobile radio terminal mobility 
transparency in the DPE. . .," the rejection of independent claim 52 is improper and 
should be reversed. 



1 A copy of this article is provided in the Evidentiary Appendix. 
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C. Tina-C and Moon Do Not Disclose or Suggest Claim 55 

Applicant has been unable to locate where the Tina-C reference describes 
mapping computational objects to engineering objects "so as to be non-visible in a 
computational model of the application program." The burden of proof to show 
where a claim feature is described in a reference is on the Patent Examiner. In re 
Piasecki, 223 USPQ 785, 788 (Fed. Cir. 1984); 37 CFR 1.104(c)(2). 

D. Tina-C and Moon Do Not Disclose or Suggest Claim 57 

Regarding claim 57, Applicant is unable to locate in the text referred by the 
Examiner where the claimed interaction between computational objects is 
described or where communication is effected between those objects "through a 
channel including stubs, binders, and protocols." In paragraphs 13 and 14 of the 
Office Action, the Examiner refers to "Chapman," which is not a reference 
identified in the formal statement of the final rejection. 

E. Tina-C and Moon Do Not Disclose or Suggest Claim 68 

Regarding claim 68, page 5-5 of Tina-C describes an object in a group 
creating another object via interaction with the group manager, which is not the 
same thing as a proxy object acting on behalf of an entity. 
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F. Tina-C and Moon Do Not Disclose or Suggest Claim 69 

Regarding claim 69, there is no mention on page 5-5 of invoking a mobility 
function operation. 

G. Tina-C and Moon Do Not Disclose or Suggest Claim 70 

A proxy object being a symmetrical consultation as recited in claim 70 is 
not described on page 5-4 of TINA-C. Where in page 5-4 is an object described as 
being represented by multiple objects? 

H. Tina-C and Moon Do Not Disclose or Suggest Claim 76 

Applicant has reviewed page 5-5 relied on by the Examiner. This page 
describes creating an object in a group. There is no teaching of introducing a 
redirection function on the DPE and generating a special stub for a dynamic object 
as recited in claim 76. 

I. The Other References Do Not Remedy Tina-C's Deficiencies 

Puder, Tokmakoff , And Leydekkers do not remedy the deficiencies of 
Tina-C or Moon with respect to independent claim 52. None of the applied 
references discloses or suggests: 

supporting mobile radio terminal mobility 
transparency in the DPE such that an application 
program being executed at a mobile radio terminal 
located in one radio service area serviced via one radio 
base station is not interrupted or hindered in its 
execution when the mobile radio terminal moves to 
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another radio service area serviced via another radio 
base station. 

VIIL CONCLUSION 

Lacking features of the claims as explained above, the Board should reverse 
the outstanding rejections. 

Respectfully submitted, 
NIXON & VANDERHYE P.C. 




JRL/kmm Reg. No. 33,149 

Enclosures 

Appendix A - Claims on Appeal 
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52. An arrangement for simplifying the design and implementation of mobile 



IX. CLAIMS APPENDIX 



radio terminal services in a communications system, comprising: 

distributed hardware and software components provided in accordance with a 

distributed processing environment (DPE) and configurable in use to provide one or more 

services to one or more users; 

means for supporting one or more distribution transparencies in the DPE including 

access, location, or failure transparencies; and 

means for supporting mobile radio terminal mobility transparency in the DPE such 

that an application program being executed at a mobile radio terminal located in one 

radio service area serviced via one radio base station is not interrupted or hindered in its 

execution when the mobile radio terminal moves to another radio service area serviced 

via another radio base station. 

53. Arrangement as claimed in claim 52, wherein the access, location, or failure 
transparencies are already existing and are defined by Open Distributed Processing 
(ODP) and adopted by Telecommunication Information Networking Architecture (TINA- 
C), and wherein the means for supporting mobile radio terminal mobility transparency in 
the DPE is added to the already-existing the access, location, or failure transparencies. 

54. Arrangement as claimed in claim 52, wherein the means for supporting 
mobile radio terminal mobility transparency in the DPE is introduced at requirement and 
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functional specification phases by integrating a mobile radio terminal mobility function 
into an infrastructure of a software platform designed in the DPE. 

55. Arrangement as claimed in claim 52, wherein the means for supporting 
mobile radio terminal mobility transparency in the DPE includes means for mapping 
computational objects to engineering objects (EO) so as to be non-visible in a 
computational model of the application program. 

56. Arrangement as claimed in claim 52, wherein means for supporting mobile 
radio terminal mobility transparency in the DPE includes an engineering object 
interceptor arranged at a boundary between a mobile radio terminal domain and a 
telecom system domain. 

57. Arrangement as claimed in claim 52, wherein an engineering model may be 
developed by mapping each of one or more computational objects (COs) to one or more 
Basic Engineering Objects (BEOs), the arrangement further comprising: 

means for effecting an interaction between computational objects belonging to a 
same cluster is effected directly using one or more method calls, and 

means for effecting communication between computational objects located in a 
telecom system domain and in different clusters through a channel including stubs, 
binders, and protocols. 

58. Arrangement as claimed in claim 52, wherein user domain computation 
objects and a telecom system domain computation object residing in different clusters 
communicate in a channel including an interceptor transparent to an application designer. 
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59. Arrangement as claimed in claim 52, wherein an application designer can 
decide from a computational model whether an object belongs to a user domain or a 
telecom system domain for use in generating application objects. 

60. Arrangement as claimed in claim 52, further comprising: 

means for sending a message to a routing broker asking for a server to perform a 

task, 

wherein the routing broker is configured to implement a mobility function to 
locate the server and send the request to the server. 

61. Arrangement as claimed in claim 60, wherein the routing broker is a cascade 
of two brokers. 

62. Arrangement as claimed in claim 61, wherein the two brokers are configured 
to allow interactions between an object belonging to a user domain and an object 
belonging to a telecom system domain. 

63. Arrangement as claimed in claim 62, wherein the two brokers support both a 
same interface type containing an invoke operation to allow a request to be built and 
invoked dynamically by client objects. 

64. Arrangement as in claim 63, wherein the invoke operation includes an object 
name or identifier, an operation name, and a parameter list for the invoked operation. 

65. Arrangement as claimed in claim 60, wherein the mobility function is a 
functional layer in a system architecture between an application layer and a DPE layer, 
where each layer may use services offered by another layer. 
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66. Arrangement as claimed in claim 60, wherein a derived computational model 
is configured for use in a transition from a computational model to an engineering model 
in the DPE to map interactions traversing a boundary between a user domain and a 
telecom system domain to interactions with the mobility function. 

67. Arrangement as claimed in claim 66, wherein based on the derived 
computational model, an engineering model can be elaborated and engineering objects 
can be generated. 

68. Arrangement as claimed in claim 60, further comprising: 

a proxy object for acting on behalf of an entity in a transparent way. 

69. Arrangement as claimed in claim 68, wherein the proxy object is adapted to 
generate an invoke operation for the mobility function. 

70. Arrangement as claimed in claim 69, wherein the proxy object is a 
symmetrical constellation. 

71. Arrangement as claimed in claim 68, wherein each proxy object is a Dynamic 
Object (DO), and a DO instance may be initiated from an object template corresponding 
to a Dynamic Object Implementation (DOI). 

72. Arrangement as claimed in claim 68, wherein a proxy represents only one 
object and is deleted when the represented object terminates. 

73. Arrangement as claimed in claim 68, wherein an object can be represented by 
multiple proxies. 

74. Arrangement as claimed in claim 68, further comprising: 



-A4- 



DO 

Serial No. 09/412,334 

means for registering in the mobility function first and second objects in different 
domains, and 

means for defining and registering a proxy for the object the proxy represents. 

75. Arrangement as claimed in claim 74, wherein objects may be grouped into 
clusters, capsules, and nodes. 

76. Arrangement as claimed in claim 52, further comprising: 

means for introducing a redirection function on the DPE and for generating a 
special stub for a dynamic object. 



-A5- 



DO 

Serial No. 09/412,334 



X. EVIDENCE APPENDIX 

Attached is a copy of a November 1997 paper entitled, "Terminal Mobility 
Support in TINA-C," delivered at a TINA-C Conference in Chile by Do van Thanh and 
Jan Audestad and a copy of a September 1996 paper entitled, "Mobility and TINA," in 
the Proceedings of the TINA 96 Conference, volume ISBN 0. 

XI. RELATED PROCEEDINGS APPENDIX 

There is no related proceedings appendix. 
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Abstract - As shown in (l] t Access and Location transpar- 
encies defined for Open Distributed Processing (ODP) and 
TINA are insufficient to support terminal mobility since 
interoperability between DPE platforms is not guaranteed 
at all times. In this paper, we study all the functions and 
computational objects necessary to support terminal 
mobility. Both forms of interactions, operational and 
stream-oriented, are considered. The solution proposed is 
generic and can be customised for both continuous and dis- 
crete mobility in either wireline or wireless networks. 

BACKGROUND 

The researched work described in this paper results from the 
mobility pan of the TELEcom REsearch Programme TEL- 
EREP, carried out at the Center for Technology at Kjeller. 
LTNIK [2]. The programme has been established to obtain 
practical experience with ODP/TTNA methods and the imple- 
mentation of TMN and IN functionality, and to study how 
security could be provided in the DPE environment. The pro- 
gramme started in 1995 and will run over several years. Ini- 
tially the programme decided to base its work on a public 
domain version of CORBA [3], and will be re-evaluated at a 
later stage. One is currently studying both theoretically and 
practically, as part of a Ph.D. programme, how mobility and 
security can be provided transparently by the platform envi- 
ronment. 



L INTRODUCTION 

There are defined two forms of interactions between compu- 
tational objects: operational and stream-oriented [4]. Support- 



ing terminal mobility consists therefore of enabling both 
forms of interactions between a Computational Object CO I 
belonging to the terminal domain and another one C02 be- 
longing to the telecom system domain (See Figure 1) 

IL ENABLING OPERATIONS BETWEEN THE 
TERMINAL DOMAIN AND THE TELECOM SYSTEM 
DOMAIN 

Prior to any operational interaction (operation invocation), a 
binding must exist between the two objects. This is called 
implicit binding, i.e objects do not explicitly request estab- 
lishment of the binding but the establishment is done by the 
DPE on the kernel transport network (kTN). This kTN is 
logically separated from the transport network supporting 
stream flows. Such a separation allows evolution of kernel 
communication independently of the evolution of the tech- 
nologies used for stream flows transport [5] (see Figure 2). 

It is observed that operational interactions between computa- 
tional objects are only possible if the kernel transport net- 
work is operative and there is always connectivity between 
two arbitrary DPE nodes, i.e every DPE node is reachable 
from every other DPE node. 

For a wired network the connectivity is ensured at configura- 
tion time, i.e necessary links between nodes are defined 
such that connectivity remains even if some nodes and links 
fails. The topology of the network is defined statically and 
will only be altered in case of a failure or reconfiguration. A 
DPE node can always determine how to reach another DPE 
node. 



^ terminal domain 




telecom system domain 



operations 
streams 



Fig. 1 Interactions between COs residing the terminal and telecom system domains 
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This is not always true with terminal mobility. The mobile 
terminal is a particular DPE node with special behaviour 

• It changes frequently the node with which it has 
direct link. 

* It may just disappear from a node and reappear lat- 
er at any other node 




m DPE Platform 



Fig. 2 The kernel Transport Network 

The topology of the kernel transport network for systems 
containing mobile DPE nodes is changing dynamically and 
more seriously, it can also be in an undetermined state in 
the sense that the connectivity with such a mobile DPE node 
is not always ensured unless additional functionally is insert* 
ed in the DPE. 

We propose to consider the kTN as consisting of two parts: 

• The fixed pan comprising all fixed DPE nodes. 

* The mobile part comprising all mobile DPE nodes. 

At the boundary of the fixed pan of the kTN there are sever- 
al Network Access Points (NAP), i.e points where mobile 
DPE nodes (terminals) can link themselves to the fixed kTN 
(see Figure 3). It is worth noting that the NAP notion is dif- 
ferent from the Network Termination Point (NTP) which 
designates the access point to the Transport network used 
for stream Hows. As specified before the kTN and the Trans- 
pon network are logically separate networks. 

An NAP object is introduced to represent an NAP on the 
kTN. An MAP object is an interceptor which stands at the 
boundary between the terminal domain and the telecom sys- 
tem domain and is responsible for checking, transforming 
and forwarding of interactions that cross the boundary. An 
NAP object has two communication interfaces, one with the 
mobile DPE and one with the fixed kTN. Several MAPs can 
be located at the same DPE node. 

Each mobile DPE node may have one or several Terminal 
Access Points (TAP), i.e. the points where the mobile DPE 
node can exchange operations with other DPE nodes. Here 



again, it is important to differentiate between a TAP and a 
Terminal Termination Point (TTP) which is used for the con- 
nection of stream flows. A TAP will be represented by a 
TAP object in the terminal domain. 

Prior to any operational interaction the mobile DPE, i.e one 
of its TAPs, must be attached to an NAP. Operational inter- 
actions between a computational object residing on a mobile 
DPE and a computational object residing on a fixed DPE al- 
ways go through a TAP and an NAP. 
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Fig.3 The kTN consisting of a fixed and a mobile 
part 

A. Interactions initiated by the fixed part 

When C02 invokes an operation opV on COl (see Eigure 
4), the operation must be sent via the correct MAP object, i.e 
the one that is currently connected with the TAP of the mo- 
bile DPE. Since the terminal is moving, the NAP to which 
the TAP is connected may change from time to time. 

To unburden C02 with mobility-related functions, a 
Texminal_Age&t Object (TA) is introduced to undertake 
a kind of relocation function as shown in Figure 4. It keeps 
track of which is the current MAP. This relocation function 
is somewhat different from a relocation function defined in 
ODP. The latter records the change in location of an object 
when its is moved from one computing node to another. But 
in fact, recording the current MAP is semantically the same 
as recording the location of the terminal and hence the loca- 
tion of object COl because the location of a terminal can be 
deduced from the locadon of the MAP. 

For each mobile DPE node (or terminal) one instance of the 
Tarmtnal_ Agent object will be instantiated. 

Instead of issuing an operation request directly to COl, C02 
issues a request to the Terminal _Agant. The 
Taxmiaal^Age&t will then forward it to the appropriate 
MAP. The MAP transfers it to the TAP which finally delivers 
it to COl. To suppon interactions initiated by the fixed pan, 
the Tenni nnl_Agent object is therefore required. 
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in fact have several TAPS which should be transparent to the 
application objects. The SPA will ensure this transparency. 
Interactions initiated from the mobile DFE are realised as 
shown in Figure 5: 

We may let the SPA involve in interactions initiated by the 
fixed part in order to obtain a symmetric interceptor configu- 
ration. Combining both types of interactions, the conveyance 
of operations across the boundary between the mobile DPE 
and the fixed DPE will be as shown in Figure 6. 



Fig. 4 Interactions initiated by the fixed part 



B. Interactions initiated by the mobile part 

Suppose now that COl wants to invoke an operation opX 
on C02 (Figure 5). First, the invocation must be conveyed 
to a TAP. This can be easily done assuming location trans- 
parency locally on ihe mobile DPE node. The TAP must 
then know to which NAP the operation should be forwarded. 
From the MAP the invocation can be conveyed to the TA 
(Tenninal_Agont) and then to C02, using access and lo- 
cation transparencies in the fixed kTN. 

It is crucial that the TAP knows which MAP instance to com- 
municate with in order to send the invocation to it. Since the 
TAP resides in a mobile DPE. the current HAP may be 
changing from time to time. The terminal mobility manage- 
ment consists in keeping track of the correct MAP instance. 
This responsibility may be allocated to the SPA object 
(Service Provider Agent). 
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Fig.5 Interactions initiated by the mobile part 



The SPA is thus entrusted with two responsibilities: support- 
ing security functions and keeping location information. In 
this way, only one interceptor object is required in the termi- 
nal for managing both security and location updating. The in- 
troduction of the SPA is also convenient to keep the TAP 
hidden from the application objects. Instead of issuing an op- 
eration invocation to C02, COl issues a request to the SPA. 
The reason is that a mobile DPE. for example a PABX may 
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Fig.6 The conveyance of operations between the mobile 
DPE and the fixed DPE 



C, Location registration and deregistration 

It is observed that the conditions for success of both types 
of interactions is the definition of the association between 
the TAP and the NAP and the definition of the association 
between the TA and the HAP. If one or both of the two asso- 
ciations arc undefined, the interaction will be unsuccessful. 
Second, the two associations must be consistent with each 
other. If the TAP is associated with an instance of MAP, then 
the TA must be associated with the same instance of NAP. 
An inconsistency will lead to failure. 

When the mobile DPE is moving, the TAP - NAP associa- 
tion and the MAP - TA association must change simultaneous- 
ly and consistently, and may sometimes be undefined. The 
operations necessary to determine these two associations arc 
commonly referred to as location registration and location 
deregistration [6]. The various methods used to determine 
these two associations constitute therefore the different strat- 
egies for location registration and location deregistration. Be- 
low we shall look at several such methods and identify how 
they can be supported by the objects proposed above. Some 
of the methods will require additional objects. We will, how- 
ever, show that the basic structure proposed above will be re- 
tained also in all cases we have identified. However, the dif- 
ferent methods will require that the TAP, MAP and TA ob- 
jects are equipped with the appropriate algorithms 
depending on the method adopted for a given system. 
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0.1 The wireline case 

In the wireline case, the association between the TAP and 
the HAP is directly reflected by and is equivalent to the phys- 
ical link between the mobile DPE and the telecom system 
domain. The association between the TAP and the HAP is 
also equivalent to the association between the TA and the 
NAP. We have: 

Physical link <=> Associadon TAP - NAP <=> Associadon 
TA - NAP 

A change in state of the physical link results in the change 
of the associadon between the TAP and the HAP and conse- 
quently a change of the association between the TA and the 
MAP. The wireline terminal can be in one of two states: reg- 
istered when the physical link is up and the associadon be- 
tween the TAP and the NAP and the association between the 
TA and the HAP are defined; de registered when the physical 
link is down and both associations are undefined. There is 
no intermediate state. 
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Fig J States of the wireline terminal 



on, any attempts to invoke operations on the mobile termi- 
nal will be denied by the TA. The terminal is in the deregis- 
tered state. 

When the physical link is established, i.e the terminal is 
plugged into the socket or switched on, the associadon be- 
tween the TAP and the HAP is defined. The NAP will imme- 
diately discover the situation and notify the TA. The TA set 
its KAP pointer to the corresponding NAP. Interactions arc 
then enabled. The terminal is in the registered state. 



Mobile kTN , Fixed kTN 



I 





J update NAP pointer 




TAP 


^ ! ». 


NAP 


connection 



disconnection 



Ftg.9 Location updating for wireline terminal 



The "physical link surveillance" method 

A change of the physical link can be used to trigger both a 
transition in terminal state and a location registration or de- 
registration. The transition of the terminal state is shown in 
figure below: 
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Fig.8 The state transition diagram of a wireline terminal 

When the physical link is broken, i.e the terminal is un- 
plugged from the socket or switched off or the line is bro- 
cen. the association between the TAP and the MAP is re- 
no ved. The MAP will immediately discover the situation and 
lotify the TA. The TA set its HAP pointer to Nil. From now 



D. The wireless case 

The wireless terminal stays most of the time in the discon- 
nected state. When die physical link is down, it does not nec- 
essarily mean that the association between the TAP and the 
NAP is removed. The mobile DPE may still be there and. 
upon request, the physical link can be re-established. The 
mobile DPE may also have moved out the area. Hence, the 
state change of the physical link does no longer reflect the 
state change of the association between the TAP and the 

NAP. 

Other methods to detect and update the change of the associ- 
ation between the TAP and the NAP are required. There are 
two alternatives: the initiative is taken either by the NAP or 
by the mobile DPE. 

1) Initiative by the NAP 
The NAP's initiative method 

The detection of the changes of the association between the 
TAP and the HAP means that the HAP is able to find out 
which mobile DPEs ore located in its area. The NAP must 
therefore have the capability to store the identifier of the 
TAPs which have been previously connected to it, i.e before 
the physical link is "broken". 



4 of 13 



Periodically, the NAP broadcasts a "hello" in its area as 
shown in Figure 10. Any mobile DPE present in the NAP's 
area will respond to the broadcast with its TAP identifier. 
The NAP will then compare the received TAP identifiers 
with the stored ones. For mobile DPEs previously registered, 
there is no change in the state of the association between the 
TAP and the NAP and no action is necessary. For mobile 
DPEs which have just arrived, the HAP issues an update call 
to the corresponding TAs. The TAs will set their NAP point- 
er to the NAP. For mobile DPEs which have left, the NAP 
also initiates an update of the corresponding TAs indicating 
that the mobile DPE did not respond. The TAs will reset 
their NAP pointer to Nil. 

If the intervals between consecutive detection processes are 
short enough, the representation of the association between 
the TAP and the NAP in the telecom system domain can be 
considered to be in agreement with the real association. The 
association is also determined for all the terminals, i.e the 
telecom system domain has the status of all the terminals. A 
terminal is registered when the TAP and the NAP association 
is defined and deregistered when the association is unde- 
fined. In registered state all interactions from and to the mo- 
bile DPE are possible. In deregistered state no interaction is 
possible. 

This solution can be used for systems where the status of 
the terminals are important. It can be used in systems with 
larger number of terminals but less geographically distribut- 
ed, i.e small number of NAPs. For systems with large 
number of NAPs, this solution has many disadvantages. 
First the NAPs must have storage capacity and consequently 
must keep the stored data, i.e TAP identifiers of mobile 
DPEs present in its area, up-to-date and consistent. Second, 
there are periodically much processing activity in every 
NAP. The third disadvantage is the inefficient use of the ra- 



dio frequency or infrared access channel to the NAP which 
is a scarce resource shared by all mobile DPEs for both data 
transmission and signalling. When all the present mobile 
DPEs answer, much capacity is used just for detection of the 
DPEs. 

2) Initiative by the mobile DPE 

a. The Periodic method 

The detection and updating of the change of the association 
between the TAP and the NAP can also be initiated by the 
mobile DPE. Each mobile DPE can periodically report itself 
to the nearest NAP. The NAP will then send a register re- 
quest to the corresponding TAs. In order to detect the silent 
terminals, i.e those that have disappeared without a deregis- 
tration. each TA can be equipped with a timeout. If a mobile 
DPE does not register itself within a period of time t^ its" 

TA will set it as deregistered. By this method, the status of 
all the terminals are always known by the telecom system 
domain. This method is suitable for systems with small 
number of terminals but which are more geographically dis- 
tributed (larger number of NAPs). 

It generates, however, activity both on the access channel 
and in the telecom system domain. 

b. The method based on location changes 

It is observed that the changes in the association between 
the TAP and the NAP are caused by the mobility of the ter- 
minal. If the mobile DPE knows that it has moved from one 
NAP to another, it also knows mat the association between 
the TAP and the NAP has to be updated. For this to work 
the mobile DPE need to have the capacity to store the identi- 
fier of the previous NAP and the capability to obtain the 
identifier of the current NAP. 
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As shown in Figure 1 1. an MAP is associated with a geo- 
graphic area called NAP coverage area. The NAP broadcasts 
periodically its identifier in this coverage area. Every mobile 
station in the coverage area reads periodically this MAP iden- 
tifier and compares it with the one stored previously. If they 
axe similar, there is no change in the association between the 
TAP and the MAP and no updating is necessary. If they are 
different, there is a change in the association. The mobile 
DPE updates its local NAP pointer and requests a regis- 
ter operation on its TA. The request is sent to the NAP 
which forwards it to the corresponding TA. The TA sets its 
SAP pointer to the current HAP. 

This alternative requires that the mobile DPE has some stor- 
age capacity and some intelligence to decide whether a regis- 
tration is necessary or not. On the other hand, the NAP does 
not have to store and process the information about the mo- 
bile DPEs present in its area. The use of the access channel 
to detect and update a change in the association between the 
TAP and the NAP is more optimal, since the probability that 
all the mobile DPEs will change NAP is very small and 
hence a total registration of ail DPEs will be very infrequent. 

The solution used in GSM [7] is slightly different from the 
one presented above. A base station can be mapped to an 
NAP in our model. There is however an intermediary object 
between the NAP and the TA. As shown in Figure 12 this ob- 
ject can be modelled as a group of NAPs, GNAP or as a 
"mirror" TA, OTA, holding some data for the TA. The loca- 
tion updating is executed only when the mobile station has 
moved from one ONAP or MTA to another. When required, 
e.g for initiating a call to the mobile DPE, the determination 
of the NAP is done "on the fly" by the GNAP or MTA.. 



There is, however, a problem. The updating of the associa- 
tions between the TAP and the NAP and the association be- 
tween the TA and the NAP are initiated by the mobile DPE 
when it knows that a change has occurred It is not always 
true that the mobile DPE is aware of such a change and ca- 
pable of notifying the telecom system domain. It can be 
switched off and brought to another area, a fault may occur 
in the mobile DPE, or it may have run out of battery power. 
It can also move out of the coverage area, loose all contact 
with the telecom system domain and be unable to initiate 
the updating. 

In such a situation there may or may not be a mismatch be- 
tween the real association between the TAP and the NAP 
and the perception of the telecom system domain, i.e the 
state of the association stored in the telecom system domain. 
When a terminal is registered, i.e the associations between 
the TA and the NAP and the association between the TAP 
and the NAP are defined, it is not guaranteed that interac- 
tions from and to the mobile DPE are possible. Only when 
the physical link is in operation, i.e there is activities to or 
from the terminal, is the state well-defined. When the physi- 
cal link is down, nothing more is known about the location 
of the mobile DPE than its previous registration. 

In the telecom system domain it is useful to differentiate be- 
tween the two registered states of the terminal, namely regis- 
tered and confirmed state and registered and uncon- 
firmed state. In addition to the NAP pointer the TA needs 
also to save the terminal state. On the mobile DPE side 
there is no need for additional state but the registered state 
and the deregistered state. The NAP pointer is sufficient to 
represent these two states. 
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Fig. 12 Alternative models of GSM 

Seen from the telecom system domain, a wireless terminal 
may therefore be in one of the following three states: 

* deregistered: the mobile station has actively noti- 
fied that it has been taken temporarily out of service. 

* registered and unconfirmed: the mobile station 
is registered at an NAP but there is no activity on 
it. i.e the physical link is down. 

* registered and confirmed: the mobile station is 
registered at an NAP and there is activity going on, 
i.e the physical link is up. 

The states of the wireless terminal is thus defined by the 
state of the physical link, the association between the TAP 
and the NAP. and the association between the TA and the 
HAP as follows: 
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Fig. 13 States of the wireless terminal 



From the registered and confirmed state the mobile DPE 
changes its state to the registered and unconfirmed state 
when all the activities have ceased. It will remain in that 
state until some successful activity takes place between the 
mobile DPE and the fixed DPE. The terminal state is then re- 
set to the registered and confirmed state. If the request is un- 
successful, the terminal state will be changed to the deregis- 
tered state and will remain there until a registration takes 
place. From the registered and confirmed state, the terminal 
state can be changed to the deregistered state when the mo- 
bile DPE has explicitly made a deregistration request or has 
disappeared, i.e does not respond to an invocation initiated 
by the fixed DPE. 

The transitions between the terminal states are shown in Fig- 
ure 14. It is worth noting that in addition to normal transi- 
tions such as registration, activation, etc. there are two spe- 
cial transitions shown in Figure 14: handover and location 
updating. In fact, the handover and location updating can be 
regarded as a transition because the associations TAP - NAP 
and TA • MAP do change, but remain defined. Location up- 
dating may be regarded as a transition from the registered 
and unconfirmed state back to the registered and uncon- 
firmed state. Similarly, handover may be regarded as a tran- 
sition from the registered and confirmed state to the regis- 
tered and confirmed state. A handover may follow a loca- 
tion updating or may be executed alone. From one 
registered and confirmed state, the terminal may also mi- 
grate to another registered and confirmed state after a loca- 
tion updating alone without a handover. 
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UL ENABLING STREAM BINDING WITH THE 
MOBILE TERMINAL 

We assume now that operational interactions can be estab- 
lished between the mobile terminal and the telecom system 
domain. From now on. in order to reduce the complexity 
and make the explanations easier, operations across the 
boundary between the mobile DPE and the fixed DPE will 
be denoted as if they are directly addressed between peer obr 
jects. although they still have to go through the objects TA, 
MAP, TAP and SPA. 

The transport network used for stream flow can be modelled 
as network delimited by two or more NTPs (Network Termi- 
nation Points) and capable of transporting bit stream be- 
tween two NTPs (see Figure 15). An NTP is the point at 
which a bit stream is accepted and/or delivered. Associated 
with an NTP is the characteristic of the stream accepted/de- 
livered at the NTP, such as frame structure. QoS, etc. Differ- 
ent NTPs may have different characteristics. 




UNA has defined a similar model called the connectivity 
layer network [8]. However, the term Access Point is used 
instead of NTP. There is actually no difference between 
these two terms. The reason that the term NTP is used in 
this paper is jusr to differentiate from the NAP (Network Ac- 
cess Point) which is the access point of the kTN (kernel 
Transport Network). It is very important to make a distinc- 
tion between the kTN and the transport network for stream. 
As mentioned in [5], these networks may be physically sepa- 
rate or share the same physical resources and represent only 
different concepts of the network. By separating the two net- 
work concepts, more freedom of choice for the kernel trans- 
port network is obtained and the evolution of the kernel 
transport network is made independent of the evolution of 
the technologies used for stream flow transport. The NTPs 
can be grouped into an NTPPool for example according to 
their geographical location. The area covered by the telecom- 
system domain can hence be divided into smaller areas, 
each one served by one NTPPool. 

As shown in Figure 16, when the mobile terminal is in area 
A, a stream flow between an object residing in the terminal 
and another object residing in the telecom system domain 
goes through a given NTPa belonging to NTPPool a . When 
the terminal leaves area A and enters, for example area B. 
then its stream flows must go through NTPb belonging to 
NTPPool fc- TCSHt must somehow be aware that the termi- 
nal has moved and that another NTP belonging to another 
NTPPool should be used. 

For each NTPPool let us define an object called 
OTP_Manager. The NTP_Manager is in charge of an 
area and has information about all NTPs in that area, i.e 
which NTPs are available and their characteristics (QoS pa- 
rameters). The NTp_Manager is periodically broadcasting 
its identifier in its area. The NTP_Manager identifier will 
be used by the TCSMfc when it wants to communicate with 
the NTP_Manager. 



NTPb 



— Connection 
• NTP 




Fig. J 5 The transport network for stream flow 



Fig. 16 The coverage area divided into area served by 
NTPPoois 
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When the terminal t is entering area A, the TCSl^ will get 
the identifier of the OTP_Jianager A , which is received 
through the TAP. Note that the kTN is used for the broad- 
cast of NTP information. Upon a connection request from 
CSM. TCSMt will ask the OTP_Manager to allocate an 
NTP for its TTP. The TCSHj. will return the identity of this 
NTP back to CSM. CSM can then request the CC to establish 
a connection between this NTP to be used for CO t object 
and the NTP to be used for CO a - 

Actually, the TCSM of the fixed node closest to the area A 
may be in charge of the allocation of NTPs. However, it is 
better to place all the connectivity functions which are spe- 
cially related to terminal mobility in a dedicate object such 
as the NTP_Manager which can be modified without any 
consequence for the TCSM. Furthermore, according to TINA 
[9], a TCSM is defined for a node in the transport network 
and the notion of coverage area presented here has nothing 
to do with a node. A coverage area may or may not corre- 
spond to a node. A node may in fact contain several areas 
when it has numerous NTPs covering a large geographical 
area which need to be grouped into smaller areas. 

The area covered by the OTP_Manager may or may not 
correspond to the area covered by the NAP since the two ob- 
jects may be responsible for the connectivity with two sepa- 
rate physical networks, the kernel transport network and the 
transport network supporting streams. 

There are three correspondence alternatives: 

1. an NAP's area corresponds to a 
OTP_Managar s area. 

2. an NAP*s area corresponds to several 
OTP_Manager s areas. 

3. an MTP_Manager's area corresponds to several 
MAP's areas. 

The choice of the appropriate correspondence alternative for 
a particular system is a matter of dimensioning and configu- 
ration and will not be studied further here. 

A. Handover 

When the mobile DPE moves from one NTP coverage area 
to another, there are two ways to support the availability of 
service: 

• Continuous terminal mobility ensures the conti- 
nuity of service by using the continuous handover 
mechanism. GSM is an example of this type of ter- 
minal mobility [7], 

• Discrete terminal mobility ensures only the conti- 
nuity of the service sessions but not the continuity 
of service, t.e the service sessions are suspended be- 
fore and during the transition and resumed when the 
mobile DPE has reached the new NTP coverage ar- 
ea. This is referred as discrete handover or session 



mobility. 
We shall now consider both cases. 
B. Continuous handover 

To ensure that stream flows are not disrupted when the mo- 
bile terminal is moving from one NTP coverage area to an- 
other, there must be an overlap between coverage areas as 
shown in Figure 17. In the intersection area AnS of two 
NTP coverage areas A and £?, the mobile terminal has con- 
tact with both NTP .Managers and stream flows can be es- 
tablished with NTPs belonging to both NTPPools. 




Fig. 17 Overlap between NTP coverage areas 



1) Handover procedure 

A handover procedure consists of the following steps: 

1. To detect that handover may be necessary. This 
can be done via the detection that the mobile DPE 
is in an intersection area such as An B or 
An5nC, etc. 

2. To decide that handover must be executed. The 
decision can be taken based on different criteria 
such as transmission quality, distance between the 
mobile DPE and the NTP. etc. The criteria are sys- 
tem dependent and cannot be implemented in a ge- 
neric way. Furthermore, the decision for handover 
can be made by the mobile DPE or by the telecom 
system domain or also by both. 

3. To perform the handover in the fastest and most 
secure way. 

4. To move to a new stable state. 

2) Necessary computational objects 

In order to realise the procedure described above, several 
new objects are required in the system. 

First, an object called Hanrlovr ^Initiator is intro- 
duced to decide and supervise the handover procedure. The 
Handover. Initiator can be created by the TCSM on 
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the mobile DPE if the handover decision should be made by 
the mobile terminal . It can also be created by the 
OTP_Manager on the fixed DPE if the handover decision 
should be made by the telecom system domain. The 
Handover_Xn± tiator object encapsulates the functions 
necessary to realise a specific decision criterion. Hence, for 
a specific system using a specific criterion, a specific ver- 
sion of the Handover_Initator is needed. All the 
Handover_Initiafcor objects have, however, the same 
operational interface toward other objects in the system. 

Second, two objects called Haadover_Source and 
Handover_Sink are introduced. Each object has at least 
three stream interfaces. The Haadover_5ource object 
has the ability to connect an input stream interface with two 
output interfaces and to duplicate the information flow form 
the input stream interface. The Handover .Sink object 
has the ability to connect two input stream interfaces into 
one output stream interface and to discard the duplicated in- 
formation from two identical input streams. In the case 
where there is a bidirectional stream flow between two ob- 
jects, it is more convenient to use an object called Hando- 
ver having the functionality of both the 
Handover_S our c a and Handover_Sink as shown in 
Figure 1 3. The binding of stream interfaces belonging to the 
same object is described in [101. 

The Handovar_Sourca should be inserted after the 
. source object using the stream direction as reference and the 
Handover.SinJc object should be inserted before the sink 
object. 




a. Handover_Source b. Handover.sink c. Handover 



Fig J 8 The Handover objects 



It is worth noting that the Handover objects in fact repre- 
sent a combination of both hardware and software modules 
which are specific to a system. Although these objects may 
have different internal functions and mechanisms they will 
have the same external interfaces. 



jects Handover t having three stream interfaces Stl, St2 T 
St3 and Handovar n having three stream interfaces Snl, 
Sn2 and Sn3. We let the mobile DPE make the handover de- 
cision through a Handover_Initiator object residing 
in the mobile DPE. 
a. Before handover 

When the CSM receives the request to bind CO t and CO n , it 
knows that CO t is residing on a mobile DPE by reading the 
name of CO t . It may then deduce that a handover object is 
necessary. It creates or requests a Service Factory object to 
create an object Handover n and proceeds with the proce- 
dure to establish a stream between GO a and the stream inter- 
face Snl of Handover n . This is done without problems 
since both CO t and Handover n are residing in the fixed 
kTN. CSM requests Handovex n to bind internally the 
stream interfaces Snl and Sn2 as shown in Figure 19 

Towards the mobile side, CSM requests TCSt^ to establish 
a local connection for CO t . TCSM^. knows that it is residing 
on a mobile DPE and that a handover object is necessary. It 
creates or requests a Service Factory object to create an ob- 
ject Handover t . It will then establish a stream between 
CO t and stream interface Stl of Handover t . TCSM^. will 
then ask Handover t to bind internally the stream interfac- 
es Stl and St2. TCSM^ requests also Handover t to bind 
St2 to TTP a . TCSMt returns the corresponding NTP identifi- 
er to which TTP a is connected, namely NTP^, to the CSM. 

The CSM then connects the Handover^ object to NTP^X- 
When this is accomplished, a stream is established between 
CO t and CO n . 

When the terminal moves into the intersection area A n B , 
TCSM t will receive the identifier of the OTP_MgXb and 

know that a handover may be necessary. It creates or re- 
quests a Service Factory to create a 
Handover.ini tiator object in the mobile DPE. 

The Handover_Iai tiator encapsulates the mechanism 
for handover decision and starts to operate immediately after 
its creation. 



3) Example of handover 

Suppose that the mobile terminal is originally in area A and 
here is a stream flow between its object CO t and another 
)bject C0 a in the telecom system domain. The stream goes 
hrough TTP a , NTP ax and NTP u . We introduce now two ob- 
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/ Terminal t 




Fig.20 The stream flow during handover 



11 of 13 



b. During handover 

When .the criterion for handover is fulfilled, the 
Handovers Initiator will start the handover procedure. 
It requests CSM to establish a stream between the interface 
St3 of Handover^ and the interface Sn3 of Haodover a . 

CSM requests the TCSMt to bind St3 to a TTP. The TCSMt 
binds St3 to TTP5. TCSh^ returns the corresponding NTP 
identifier to which TTP5 is connected, namely NTPgX' t0 
the CSM. CSM then connects the Eandover n object to NTP- 

BX- 

Everything has now been prepared for the switchover. The 
Handover_Iaitiator requests Handover^ to bind in- 
tern ally the interfaces Stl and St3, and Handover^ to bind 

internally the interfaces Sn 1 and Sn3. The 
Handover_Initiator then requests CSU to release the 
stream between the interfaces St2 of Haadover t object 
and Sa2 of Handover^ object. It also requests Hando- 
ver t object to unbind internally Stl and St2 and Hando- 
ver^ to unbind Sn 1 and Sn2. 

In Figure 20 we just show that there are interactions be- 
tween the Handover_Initiator and the CSM, and 
Handover t and Handovor n without any further specifica- 
tion in order to preserve clarity. 



c After Handover 

As shown in Figure 21, after the accomplishment of the 
handover procedure the Handov«r_Iaitiator object 
will terminate itself. The stream between the objects CO t 
and CO n follows now the new path without disruption. 



D. Discrete handover 

Without overlap between the NTP coverage areas, the mo- 
bile DPE will loose all contact with the telecom system do- 
main when it moves out of an NTP coverage area. The conti- 
nuity of service cannot be ensured. However, the service ses- 
sions in use can be suspended in order to be resumed later 
when the mobile DPE arrives at the new NTP coverage ar- 
ea- In a way, the service sessions can be considered as non : _ 
disrupted. The continuity of sessions requires the interven- - 
tion of the user, i.e the user must explicitly order the suspen- 
sion of the sessions in use before moving to another NTP ar- 
ea. He must also explicitly resume these sessions later on. 

V. CONCLUSION 

We have shown how terminal mobility can be supported in 
TINA architecture. To support mobility, the following mobil- 
ity computational objects are required: 




Fig.21 The stream flow after handover 
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a. To support operational interactions: 

• In the mobile DPE: 

- SPA 

- TAP 

• In the telecom system: 

- TA 

- HAP 

- Tarminal_Data 

b. To support stream flows: 

• In the mobile DPE: 

- Handover objects 

- Handover_lnitiator 

• In the telecom system 

- NTP — Manager 

- Handover objects 

- Handover_Initiator 

In addition, the following objects defined by the TINA Con- 
nection Management need to have enhanced functionality in 
order to cooperate with the mobility-related objects: 

• CSM 

• TCSM 

These two objects must interact with the mobility objects 
such as the TA, the SPA. etc. in order to support streams. 
They must have the ability to distinguish between objects re- 
siding on a mobile DPE and objects residing on the fixed 
DPE." in order to decide about the creation of the Hando- 
ver obiects for streams spanning the terminal domain and 
the telecom system domain. The TCSM must also have the 
ability to detect that a handover may be necessary in order 
to create the Handover_Initiator object which con- 
trols the handover procedure. 
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1 Introduction 

The main goal of the SANDRA (Services And Network Database Research Activity) project at 
the Center for Technology at Kjeller is to try out the concepts and principles of TINA [9] in the spec- 
ification, design and implementation of telecommunications applications, especially mobile applica- 
tions. One objective of the project is to make the realization of mobile applications simpler by mask- 
ing from the application all the mechanisms necessary to handle mobility, i.e making mobility part 
of the engineering viewpoint. This is done partly by using transparencies defined by UNA and part- 
ly by identifying additionnal functions not yet supported by the TINA DPE (Distributed Processing 
Environment) [8], [5]. As a case of study. Universal Personal Telecommunications (UPD [1], [3] 
will be designed and implemented in a TINA-compIiant manner. A CORBA-implementation [4], OR- 
Beline, from PostModern Computing Technologies, Inc. is used as TTNA-DPE. 

2 Mobility is seamlessly supported in an ideal model 

Let us start with an ideal situation where there exists a large DPE underneath all the computation- 
al objects and supporting access and location" transparencies. In such ideal model, an object User A 
can move anywhere and still receive telecommunication services. To reach User A, any other objects 
just need its reference or ID and uses access and location transparencies to find it. The same reason- 
ing can be applied to a terminal. Thus, the access and location transparencies will ensure that a 
stream can always be established between two Terminal objects independently of their locations. It is 
therefore possible to conclude that: 

In an ideal model where a large DPE supporting access and location transparencies is as- 
sumed, personal mobility and terminal mobility is seamlessly supported. 

3 Mobility is not automatically supported in a real model 

For two reasons, this model is too ideal. First, if the User is a human being, there is no DPE in 
the end-user. A User must, therefore, in general be considered as a non-DPE node. Further, the User 
(viewed as an object) cannot belong to the same administrative and technological domain [7] [2] as 
the telecommunications system. In the domain 'Telecom System", it is necessary to introduce an in- 
terceptor (as defined in [2]), called PDJJser_Agent (Provider Domain User Agent), which represents 
the User and is responsible for protection and security functions. All the requests addressed to a User 
are then issued to the PD_User_Agent Personal mobility depends on the PD_User_ Agent's ability to 
locate the user. Without this ability, personal mobility is not supported. Similarly second, a Terminal 
should also be considered as a separate domain. In the domain *Telecom_System'\ a 
PD_Terminal_Agent represents the Terminal. The Agent will be responsible for security functions,-. 
i.e identification and authentication of the terminal. Terminal mobility depends on the 
PD_Terrninal_agent*s ability to locate the terminal. It is therefore possible to conclude that: 

In a realistic model, where domain concept are taken into account, persona] and terminal 
mobility are no longer automatically supported by ODP transparencies alone. 

4 Offering mobility transparency to the applications 

In order to support personal mobility, the PD_User_Agent must be equipped with the function to 
store and update user location information It is worth noting that the location information is subject 
to frequent change due to the mobility of the user. The PD_User_ Agent must have an operational in- 
terface allowing the User to register his location. 

Concerning terminal mobility, the mobile terminal is a particular DPE node with .special behav- 
iour: 

* It changes access node frequently. 



^, 20 Feb 04 15^49 . TELENOR FoU +47 67891814 p,2 



• It may just disappear for a while and re- appear at a diiferent access node. 

The topology of the kernel Transport Network (kTN) is changing dynamically and, more serious- 
ly, it can also be in an undetermined state. The connectivity with such a mobile DPE node is not al- 
ways ensured unless additional functions are inserted in the DPE. We propose to consider the kTN 
as consisting of two parts: 

• A fixed part consisting of all fixed DPE nodes. 

• A mobile part consisting of all mobile DPE nodes. 

At the boundary of the fixed part of the kTN, there are several Network Access Points (NAP), i.e 
points where mobile DPE nodes (terminals) can connect themselves to the fixed kTN. On each mo- 
bile DPE node, a Mobility^Mgr object assumes the responsibility of connecting the mobile DPE to 
the fixed kTN. Interactions between a computational object residing on a mobile DPE and object on 
a fixed DPE always go through a NAP object and a Mobility_Mgr object.. Supporting terminal mo- 
bility means therefore to maintain dynamically the associations between Mobility_Mgr and NAP and 
between NAP and PD_Term_Agent. 

In order to verify all the concepts and ideas concerning the support of mobility, a simulated sys- 
tem is designed and built. Horizontally, the system is structured into separate functional layer Serv- 
ice Layer, Mobility Layer and Resource Layer. Vertically, the system is divided into two domains: 
Terminal Domain and Telecom Domain (fig. 4.1). 



Terminal Domain 



Telephony_Display 



s*3 



Mobility__Mgr 




Telecom Domain 



Telephony_Scrvice 



NAP 



PD_User_Agent 



PDJTerm_Agent 



Terminal Locator 




Figure 4.1; Simulated environement at die Center for Techonlogy at Kjeller 

5 Conclusion 

We have shown that personal and terminal mobility can be supported in TINA architecture. In or- 
der to offer mobility transparency to the applications, a functional layer called Mobility Layer is re- 
quired. Such Mobility Layer facilitates the construction of mobile applications and promotes re-use 
in specification, design and coding. Our implementation is however rudimentary and several issues 
are left for further study such as replication and migation strategies for the agents, more advanced 
transaction mechanisms, etc. 

More extensive paper on this problem can be obtained by request to Mr. Do van Thanh, 
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